Software developers often use an Object-Relational Mapping (ORM) tool when building applications. At a high-level, an ORM abstracts software developers from the database. Instead of interacting directly with the database's relational model using Structured Query Language (SQL), a developer can instead leverage an ORM to translate an object-oriented model to/from the relational model. The object-oriented model is written in the same code/language as the developer is building the application.
The ORM allows developers to work with a database without actually writing database access code and/or SQL code. The ORM automatically translates the developer's object-oriented code to SQL queries that the ORM then sends to the database for execution.
Because the ORM abstracts the database, the software developer may not know or even understand what is really going on “under the covers” in the database. Oftentimes, the SQL dynamically generated from the developer's code is not optimal. It may result in a poor performing SQL query.
In this example, a Database Administrator may identify a poor performing SQL query running in the database. Because the SQL is dynamically generated by the ORM, it is currently not possible to know what code is actually responsible for that query. As a result, Developers or Database Administrators cannot trace a SQL query back to the originating code. This is especially true in a production environment (where users are more likely to discover a poor performing SQL query) because it is much harder to debug and/or hook up diagnostic tools.
These and other drawbacks exist.